Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models

Software projects can often spiral out of control to become “runaway systems” that far exceed original budget and schedule projections. The behavior that underlies many runaway systems can best be characterized as “escalation of commitment to a failing course of action.” The objectives of this study were to: (1) understand the extent to which IS projects are prone to escalate, (2) compare the outcomes of projects that escalate with those that do not, and (3) test whether constructs associated with different theories of escalation can be used to discriminate between projects that escalate and those that do not. A survey was administered to IS audit and control professionals and, to establish a baseline for comparison, the survey was designed to gather data on projects that did not escalate as well as those that did escalate. The results of our research suggest that between 30% and 40% of all IS projects exhibit some degree of escalation. Projects that escalated had Keil et al./Software Project Escalation 632 MIS Quarterly Vol. 24 No. 4/December 2000 project outcomes that were significantly worse in terms of perceived implementation performance and perceived budget/schedule performance, as compared to projects that did not escalate. Using constructs from theories that have been used to explain the escalation phenomenon, we were able to test various logistic regression models for their ability to discriminate between projects that escalate and those that do not. To construct our models, we explored constructs derived from selfjustification theory, prospect theory, agency theory, and approach avoidance theory. While constructs derived from all four theories were significant in logistic regression models, the completion effect construct derived from approach avoidance theory provided the best classification of projects, correctly classifying over 70% of both escalated and non-escalated projects.